My CUCM SRND Design Notes 10.X – SIP TRUNK Deployments

Best Effort Early Offer [Early Offer support for voice and video calls Best Effort (no MTP inserted)]

Best Effort Early Offer can be enabled on the SIP Profile associated with the SIP trunk, and it is the recommended configuration for all Unified CM and Unified CM Session Management Edition (SME) trunks. Best Effort Early Offer trunks never use MTPs to create an Early Offer and, depending on the calling device, may initiate an outbound SIP trunk call using either Early Offer or Delayed Offer. Best Effort Early Offer SIP trunks support voice, video, and encrypted calls.

Best Effort Early Offer SIP trunks send outbound calls with an Early Offer (INVITE with SDP content) in the following situations:

• An inbound call to Unified CM or SME is received over a SIP trunk using Early Offer.
• An inbound call to Unified CM or SME is received over an H.323 trunk using Fast Start.
• An inbound call to Unified CM or SME is received over an MGCP trunk.
• A call is initiated from a SIP-based IP phone registered to Unified CM.
• A call is initiated from a newer model SCCP-based Cisco Unified IP Phone registered to Unified CM.

Best Effort Early Offer trunks send outbound calls with a Delayed Offer (INVITE without SDP content) in the following situations:

• An inbound call to Unified CM or SME is received over a Delayed Offer SIP trunk.
• An inbound call to Unified CM or SME is received over an H.323 Slow Start trunk.
• A call is initiated from an older model SCCP-based IP phone registered to Unified CM.

Figure 6-14 Best Effort Early Offer

Media resources such as MTPs for DTMF translation, trusted relay points (TRPs), and transcoders for codecs mismatches can still be associated with and used by a Best Effort Early Offer trunk. Note that with Best Effort Early Offer , MTPs are never used to create an Early Offer or to create an Answer in response to a received Offer.

Using Best Effort Early Offer for all SIP trunks in your enterprise simplifies Cisco Collaboration System network design and deployments, and it eliminates the need to use MTPs to generate an Offer. Note, however, that Cisco Collaboration call control systems, applications, and gateways may receive either an Early Offer or Delayed Offer call over a Best Effort Early Offer trunk, and they should be able to receive either. All Cisco Collaboration System applications support the receipt of either Early Offer or Delayed Offer calls.

In certain cases (for example, calls via a Cisco Unified Border Element Session Border Controller (SBC) to a service provider’s IP PSTN), Early Offer must always be sent to the IP PSTN. In these situations, use Cisco Unified Border Element’s Delayed Offer to Early Offer feature to convert a received Delayed Offer to Early Offer.

If your Cisco Collaboration System application must receive either Early Offer only or Delayed Offer only, you can use a Unified CM SIP trunk configured for Early Offer (using Early Offer support for voice and video calls Mandatory (insert MTP if needed) or MTP Required ) or Delayed Offer, respectively, to connect to this application. With single Unified CM cluster deployments, these trunk choices are straightforward. For multi-cluster deployments interconnected via Unified CM Session Management Edition, where a single SIP trunk can be shared to reach many end Cisco Collaboration Systems, Best Effort Early Offer is recommended for all SME trunks. For more information on the design considerations for Best Effort Early Offer

 

MTP-Less Early Offer, Best Effort Early Offer, and SME Media Transparency

MTP-Less Early Offer is a special SIP trunk configuration for Unified CM Session Manager Edition (SME) cluster versions that do not support the Best Effort Early Offer feature. Best Effort Early Offer provides the same functionality as MTP-Less Early Offer ; but whereas MTP-Less Early Offer deployments require that no media resources are configured on the SME cluster, with Best Effort Early Offer , media resources can be configured if needed. SME deployments using only Best Effort Early Offer or MTP-Less Early Offer SIP trunks allow you to deploy an SME cluster that is media transparent (no media resources are required in the SME cluster) because all media negotiation takes place in the leaf Unified Communications systems, which insert media resources (MTPs, transcoders, and so forth) as required. (See Figure 6-15.)

MTP-Less Early Offer takes advantage the Unified CM SIP service parameter Fail Call Over SIP Trunk if MTP Allocation Fails . The default setting for this service parameter is False , thus allowing an inbound Delayed Offer call to proceed over the outbound SIP trunk (configured for Early Offer) as a Delayed Offer call if no MTP resources are available.

Figure 6-15 Using MTP-Less Early Offer for SME Media Transparency

To configure a media-transparent SME cluster using MTP-less Early Offer:

• Use only SIP trunks on the SME cluster.
• Enable all trunks with Early Offer support for voice and video calls Mandatory (insert MTP if needed) .
• Disable the IPVMS service on all SME nodes. This disables Unified CM media termination points, conferencing, music on hold, and annunciator resources.
• Do not associate any Cisco IOS media resources with the SME cluster.
• Configure SIP trunk DTMF settings to No Preference (the default setting).
• Enable Accept Audio Codec Preference in Received Offer on all SME SIP trunks.

Figure 6-16 Using Best Effort Early Offer for SME Media Transparency

To configure a media-transparent SME cluster using Best Effort Early Offer :

• Use only SIP trunks on the SME cluster.
• Enable all trunks with Best Effort Early Offer .
• Configure SIP trunk DTMF settings to No Preference (the default setting).
• Enable Accept Audio Codec Preference in Received Offer on all SME SIP trunks.

Media Termination Points

MTPs are used by Unified CM for the following purposes:

• To deliver a SIP Early Offer over SIP trunks
• To address DTMF transport mismatches
• To act as an RSVP agent
• To act as a Trusted Relay Point (TRP)
• To provide conversion between IPv4 and IPv6 for RTP streams

MTPs are available in three forms:

• Software MTPs in Cisco IOS gateways — Available with any Cisco IOS T-train software release and scaling up to 5,000 sessions (calls) on the Cisco Aggregation Services Routers (ASR) 1000 Series with Route Processor RP2.
• Hardware MTPs in Cisco IOS gateways — Available with any Cisco IOS T-train software release, hardware MTPs use on-board DSP resources and scale calls according to the number of DSPs supported on the Cisco router platform.
• Cisco Unified CM software MTPs using the Cisco IP Voice Media Streaming Application on a Unified CM subscriber node

Cisco IOS MTPs are recommended over Unified CM MTPs because Cisco IOS MTPs provide additional scalability and greater functionality, such as support for additional codec types, multiple media streams, and the pass-through codec

 

User Identity and SIP Trunks

A calling user’s name and number can be sent over Unified CM SIP trunks in the following SIP message headers:

The From and To message headers sent in SIP Requests and Responses indicate the direction of the call. (The From header represents the calling user and the To header represents the called user.) The From and To headers remain the same in all SIP Requests and Responses for the call.

SIP allows the From header to be made anonymous so that the calling user information is not presented to the called user.

The P-Asserted-Identity and Remote-Party-ID headers (if present) always contain the user’s identity. The user information contained in SIP messages with these identity headers is directional, so that the headers contain the calling user’s identity in an Initial INVITE and the called user’s identity in Responses. The P-Asserted-Identity and Remote-Party-ID headers can be used to trace the identity of an anonymous call.

By default, both the P-Asserted-Identity and Remote-Party-ID headers are sent over Unified CM SIP trunks, but they can be disabled. The usage of P-Asserted-Identity and Remote-Party-ID headers will depend upon the device that the Unified CM SIP trunk is connected to. P-Asserted-Identity is a more recent standard and more commonly used than Remote-Party-ID. The P-Asserted-Identity standard (RFC 3325) is considered to be more secure than Remote-Party-ID because it supports authentication between untrusted SIP Realms. For SIP trunk connections to untrusted networks, configure Unified CM to send a P-Preferred-Identity header instead of a P-Asserted-Identity header. Unified CM will respond to a Digest authentication challenge for the sent the P-Preferred-Identity header.

 

Reasons for Using Only SIP Trunks in Cisco Collaboration Systems Deployments

For Cisco Collaboration Systems networks consisting of one or more Unified CM clusters, Unified Communications applications, Session Border Controllers, and gateways, using SIP as the sole interconnecting trunk protocol allows you to build a simplified Collaboration Systems network with a rich set of common features.

When compared to other trunk protocols, SIP trunks today support a number of unique features, such as:

• SIP OPTIONS Ping which tracks the overall operational status of the trunk and the state of each trunk’s destination nodes.
• Codec Preference Lists and the ability to accept the codec preferences received in an SDP Offer.
• Support for H.264 video with BFCP-based presentation sharing and Far End Camera Control.
• SIP message normalization and transparency, which provides powerful script-based functionality for SIP trunks that can be used to transparently forward and/or modify SIP messages and message body (SDP) contents as they traverse Unified CM. Normalization and transparency scripts are designed to address SIP interoperability issues, allowing Unified CM to interoperate with SIP-based third-party PBXs, applications, and IP PSTN services.
• Support for IPv4 only, IPv6 only, or Dual Stack (IPv4 and IPv6) ANAT-enabled SIP trunks.

Design and Configuration Recommendations for SIP Trunks

When designing and deploying a SIP-based Cisco Collaboration Systems network, Cisco recommends that you use the following SIP trunk features:

Best Effort Early Offer for Unified CM Leaf Clusters and SME Clusters

Using only SIP trunks configured as Best Effort Early Offer , eliminates MTP usage for Early Offer creation in leaf clusters and makes SME clusters transparent to media negotiation. With Best Effort Early Offer , the SIP trunk sends an Early Offer only if it has enough information about the calling device’s media capabilities to create the Offer; if it does not have this information, it sends a Delayed Offer instead.

Prior to Best Effort Early Offer , the decision to use Delay Offer or Early Offer on leaf cluster trunks was typically based upon the number of older SCCP endpoints registered to the cluster. Because older SCCP endpoints require the insertion of an MTP to create an Offer for calls over Early Offer SIP trunks, where large numbers of SCCP endpoints exist within the cluster, Delayed Offer was preferred to avoid MTP usage. Best Effort Early Offer removes the need to decide upon Early Offer or Delayed Offer SIP trunk configuration based on the type of endpoints registered to the cluster.

In Cisco Collaboration System deployments, receipt of Early Offer only may be required by non-Cisco Unified Communications applications and services. There are two options to address the requirement that Early Offer is always received:

• Cisco Unified Border Element provides a SIP Delayed Offer to Early Offer feature for voice calls, which converts inbound Delayed Offer calls to outbound Early Offer calls, thus allowing Unified CM and SME to use Best Effort Early Offer trunks. A typical example of this use case is service provider IP PSTN connections, which typically must always receive SIP Early Offer.
• For enterprise Unified Communications applications that accept only SIP Early Offer, a dedicated Early Offer SIP trunk can be used from the Unified CM Leaf cluster to the Unified Communications application. If a large number of MTPs are required on the Early Offer SIP trunk, consider using the Cisco Unified Border Element Delayed Offer to Early Offer conversion feature.

In SME clusters, Best Effort Early Offer performs the same role as MTP-Less Early Offer by making the SME cluster transparent to media negotiation, which in turn forces media decisions to be made by the end Unified Communications system where, if required, media resources can be inserted to address DTMF or codec mismatch issues. Media resources must not be associated with MTP-Less Early Offer SME trunks. If needed, media resources can be associated with Best Effort Early Offer trunks.

Run on All Unified CM Nodes

This feature is supported on SIP trunks and route lists, and it greatly simplifies call routing from and through Unified CM and SME clusters. Cisco highly recommends enabling the Run on all Unified CM nodes feature on all SIP trunks and route lists. Call routing is simplified through a combination of the Run on all Unified CM nodes and the Route Local features, whereby phone calls over SIP trunks will always originate from the Unified CM node where the phone is registered. Likewise for trunk to trunk calls, the outbound SIP trunk call will always originate from the Unified CM node on which the inbound Trunk call arrived. Enabling Run on all Unified CM nodes on all SIP trunks and route lists eliminates the need to set up calls between call processing nodes within the cluster, which can be useful when clustering over the WAN is deployed within a Unified CM or SME cluster.

Up to 16 SIP Trunk Destination IP Addresses

SIP trunks can be configured with up to 16 destination IP addresses, 16 fully qualified domain names, or a single DNS SRV entry. Support for additional destination IP addresses reduces the need to create multiple trunks associated with route lists and route groups for call distribution between two Unified Communications systems, thus simplifying Unified CM trunk design. When IP addresses are used as destinations on a SIP trunk, Unified CM randomly distributes calls across all defined destination IP addresses.

SIP OPTIONS Ping

Enable the SIP OPTIONS Ping feature on the SIP Profile associated with a SIP trunk to dynamically track the state of each the trunk’s destinations and the overall state of the trunk.

PRACK

PRACK provides reliability of 1XX responses for interoperability scenarios with the PSTN, and it can also be used to reduce the number of SIP messages that need to be exchanged before setting up two-way media. Enable PRACK through the SIP Rel1XX Options parameter on the SIP Profile associated with the trunk.

SIP Trunk DTMF Signalling Method – No Preference

Using DTMF Signalling Method: No Preference is recommended on SIP trunks because in this mode Unified CM attempts to minimize the usage of MTP resources by selecting the most appropriate DTMF signalling method (in-band or out-of-band) for the call.

 

The upgrade process for an SME cluster consists of two key parts:

• Version switch-over — The call processing node is rebooted and initialized with the new software version (this takes approximately 45 minutes per server).
• Database replication — The subscriber’s database is synchronized with that of the publisher node.

The time taken to complete this database replication phase depends on the number of subscribers nodes in the cluster and the RTT between the publisher and subscriber nodes. The database replication process has a minimal impact of the subscriber’s call processing capability and typically can be run as a background process during normal SME cluster operation. Avoid making changes to the SME cluster configuration during the database replication phase because this increases the time it takes to complete the replication.

For SME clusters deployed with extended RTTs, before upgrading the cluster, run the following administrator-level CLI command on the publisher node:

utils dbreplication setprocess 40

This command improves replication setup performance and reduce database replication times.

Figure 6-23 Unified CM Session Management Edition – Clustering over the WAN with Extended Round Trip Times

SIP TRUNKS #

Using the latest Cisco Collaboration Systems Release and SIP trunks across all Unified CM leaf clusters and the SME cluster enables your deployment to benefit from common cross-cluster features such as codec preference lists, ILS, GDPR, and Enhanced Locations call admission control (CAC). If you do not wish to upgrade to the latest Unified CM version on all clusters, the lowest recommended version is Cisco Unified CM 8.5 using SIP trunks because this version includes features that improve and simplify call routing through Unified CM and Session Management Edition clusters.

Recommendations for Unified CM Leaf Clusters:

• Configure one SIP trunk to each set of SME nodes in each regional data center. For example, if there are four regional SME data centers, create four SIP trunks in each leaf cluster (see Figure 6-24). This allows calls from all SME nodes to be received and accepted by the leaf clusters. Enable Run on all Unified CM nodes on all of these trunks.
• Place two or more of these leaf cluster SIP trunks into a route list and route groups for path redundancy to the SME CoW+ cluster.
• Best Effort Early Offer is recommended for all leaf cluster SIP trunks.

In Unified Communications deployments, receipt of Early Offer only might be required by non-Cisco Unified Communications applications and services. For leaf clusters, there are two options to address the requirement that Early Offer is always received:

– Cisco Unified Border Element provides a SIP Delayed Offer to Early Offer feature for voice calls, which converts inbound Delayed Offer calls to outbound Early Offer calls, thus allowing Unified CM and SME to use Best Effort Early Offer trunks. A typical example of this use case is for service provider IP PSTN connections via Cisco Unified Border Element, which typically must always receive SIP Early Offer.

– For enterprise Unified Communications applications that accept only SIP Early Offer, a dedicated Early Offer SIP trunk can be used from the Unified CM Leaf cluster to the Unified Communications application. If a large number of MTPs are required on the Early Offer SIP trunk, consider using the Cisco Unified Border Element Delayed Offer to Early Offer conversion feature instead.

• Enable the IPVMS service on all leaf cluster nodes. Activate conferencing, music on hold, and annunciator resources as required. (Deactivating IPVMS-based MTPs is recommended.)
• As required, configure and associate Cisco IOS media resources (MTPs, conferencing, and transcoding) with the leaf cluster.
• Configure SIP trunk DTMF settings to No Preference (the default setting).
• Enable SIP Options Ping and PRACK.
• If required, configure and apply codec preference lists.

Recommended Trunk Configuration for CoW Leaf Cluster Trunks

Recommendations for Session Management Edition Clusters:

• Use only SIP trunks on the SME cluster.
• Configure one SIP trunk from the SME cluster to each leaf cluster (see Figure 6-25). Enable Run on all Unified CM nodes on these trunks, and configure trunk destinations to every call processing node in the leaf clusters.
• Best Effort Early Offer is recommended for all SME cluster SIP trunks.

If receipt of Early Offer only is required by non-Cisco Unified Communications applications and services connected to SME clusters, there are two options to address the requirement:

– Cisco Unified Border Element provides a SIP Delayed Offer to Early Offer feature for voice calls, which converts inbound Delayed Offer calls to outbound Early Offer calls, thus allowing Unified CM and SME to use Best Effort Early Offer trunks only. A typical example of this use case is for service provider IP PSTN connections via Cisco Unified Border Element, which typically must always receive SIP Early Offer.

– For enterprise Unified Communications applications that accept only SIP Early Offer, if a dedicated Early Offer SIP trunk is used from the SME cluster to the Unified Communications application, media resources will have to be associated with the SME trunks, which if used will cause unwanted media hair-pinning. The media resources typically used in this case are MTPs to create an Early Offer or address DTMF mismatches and transcoders to address codec mismatches. Using media resources in the SME cluster is not generally recommended; as an alternative, consider using the Cisco Unified Border Element Delayed Offer to Early Offer feature between SME and the Unified Communications application, or use a direct trunk to the application from the leaf cluster.

• Disable the IPVMS service on all SME nodes. This disables Unified CM media termination points, conferencing, music on hold, and annunciator resources.
• Do not associate any Cisco IOS media resources with the SME cluster.
• Configure SIP trunk DTMF settings to No Preference (the default setting).
• Enable Accept Audio Codec Preference in Received Offer on all SME SIP trunks.
• Enable SIP Options Ping and PRACK.

 

Minor Features of Unified CM SIP Trunks

This section describes the function and usage of several minor features available on Unified CM SIP trunks.

Send sendrecv in Mid-Call INVITE

This feature is used to address interoperability issues with third-party products. When Unified CM places a call hold over a SIP trunk, it sends a mid-call INVITE with audio direction media attribute a=inactive in the SDP body to disconnect the media connection. On call resumption, Unified CM sends a Delayed Offer INVITE (without SDP) to the held device to obtain its media characteristics through an SDP Offer. According to RFC 3261 (section 14.2), the held device should construct the Offer as if it were making a new call; that is, with a list of all supported codecs and a=sendrecv. Some third-party products respond with only the last used codec and media direction attributes, with the result that the call always remains in the inactive state and media cannot be resumed. When Send “sendrecv” in mid call INVITE is enabled, this feature inserts an MTP into the media path between the calling and calling devices, allowing the media connection to be disconnected between the Unified CM device and the MTP, while establishing and maintaining media between the MTP and the held device with a=sendrecv. On call resumption, the MTP is removed from the media path. This feature addresses the mid-call Delayed Offer INVITE issue for audio direction, but it cannot resolve the issue of a device responding with its last used codec rather than the full list of all supported codecs. This issue can be problematic in cases where a codec change is required on re-establishment of media, such as placing a G.729 call on hold and connecting it to a music on hold source where G711 is preferred.

 

Disable Early Media on 180

By default, Cisco Unified CM signals the registered calling phone to play local ringback if SDP is not received in a 180 Ringing or 183 Session Progress Response.

If SDP is included in the 180 or 183 Response, instead of playing ringback locally, Cisco Unified CM connects media, and the calling phone plays whatever the called device is sending in its media stream (such as ringback or busy signal).

If ringback is not received, the device to which you are connecting might be including SDP in the 180 response, but it is not sending any media before the 200 OK response. In this case, check this check box to play local ringback on the calling phone and connect the media upon receipt of the 200 OK response

Redirect by Application

When enabled, the Redirect by Application feature allows Unified CM to:

• Apply a specific calling search space to redirected contacts that are received in the 3xx response.
• Apply digit analysis to the redirected contacts to make sure that the call gets routed correctly.
• Prevent a DOS attack by limiting the number of redirection (recursive redirection) requests
• Allow other features to be invoked while the redirection is taking place.

If the Redirect by Application check box is unchecked, outbound SIP trunk calls can be redirected to a restricted phone number (such as an international number) because redirection is handled and routed at the SIP stack level without intervention of Unified CM digit analysis and class of service.

Re-Route Incoming Request to New Trunk Based on

Inbound SIP trunk calls to Unified CM will be accepted only if the source IP address and port number of the calling device match the destination IP address and port number of a configured SIP trunk. Once the call has been accepted, it can then optionally be re-routed to another Unified CM SIP trunk based on information contained within the received SIP message header.

By default, calls are never re-routed after being matched to a SIP trunk based on IP address and port number.

Optionally, incoming Requests can be re-routed to a new trunk based on the received:

• Contact header

The call is re-routed to another SIP trunk based on the IP address and port number received in the contact header. This feature is typically used to re-route calls from a SIP Proxy to a Unified CM SIP trunk assigned to a specific end user or system.

• Call-Info Header with purpose=x-cisco-origIP

This option is used to match inbound calls from Cisco Unified Customer Voice Portal (CVP) to a specific trunk based on the IP address and port number contained in the Call-Info header parameter purpose=x-cisco-origIP. This feature is typically used to map calls from Unified CVP to Unified CM trunks for call admission control.

Overwriting Caller ID Number and Name in Outbound Trunk Calls

This feature can be useful if, for example, you wish to send a company switchboard number and company name instead of the caller’s number and name in the SIP messages of calls sent over the SIP trunk. (See Figure 6-27.)This feature can be applied at the device level (for branch offices using a centralized SIP trunk) or at the trunk level.

At the device level, use the Caller ID DN and Caller Name fields of the Incoming Requests FROM URI Setting section on the SIP Profile associated with the device.

At the trunk level, use the Caller ID DN and Caller Name fields of the Outbound Calls – Caller Information section of the trunk configuration page.

By default the Caller ID DN and Caller Name sent in the From header, Contact header, and P-Asserted-Identity and Remote-Party-ID headers are modified in outbound SIP trunk calls. If you wish to keep the original Caller ID in the P-Asserted-Identity and Remote-Party-ID headers, check the Maintain Original Caller ID DN and Caller Name in Identity Headers check box on the trunk configuration page. Checking this check box allows the originator of the call to be traced.